home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Tools & Utilities
/
Collection of Tools and Utilities.iso
/
c
/
tcomm50.zip
/
LXM.DOC
< prev
next >
Wrap
Text File
|
1988-01-30
|
26KB
|
1,113 lines
INTRODUCING LXM
BRIEF HISTORY OF XMODEM
During the glory days of CP/M, the computer industry was
plagued with a plethora of diskette formats. Since there was
no single standard around, particularly when the 5" format
was introduced, data interchange between computers was
difficult.
Several manufacturers attempted to provide a solution by
giving their users the ability to at least read multiple
diskette formats. Rather than promoting a standard format,
this approach encouraged manufacturers to adopt proprietary
formats as a marketing tool. Partially as a response to this
situation, and partially out of a need to provide data
transmission capabilities, Ward Christiansen developed the
original specification for the XModem file transfer
protocol.
The XModem protocol, elegant in its simplicity and
effectiveness, has transcended the decline of CP/M-based
systems, and the ascendency of MS-DOS to become a de facto
standard for data transfer between remote computers. This
fact is true, even in the light of the near-universal
acceptance of another de facto standard for diskette
formats, as popularized by the IBM-PC family. With the
advent of the new PS/2 with its incompatible micro-
diskettes, the XModem protocol's place, at least for the
foreseeable future, seems assured.
PROTOCOL FUNDAMENTALS
THE TRANSMISSION BLOCK
The fundamental building block of XModem is an 8-bit byte,
no parity please, arranged into transmission blocks of
exactly 132 characters, never more nor less. In one
extension to XModem, commonly called CRC-XModem, the
transmission blocks are exactly 133 characters. We will
discuss this extension , and a second known as YModem,
later.
LXM(tm) - LITECOMM (tm) XMODEM ENGINE for Microsoft
Datalight and Turbo C
As you might guess, not only is the length of a transmission
block fixed, but so too is the format. The XModem block
format looks like this:
<SOH> <REC> <~REC> <...128 Data Bytes...> <checksum>
where:
SOH - 0x01 Signals the start of a block
REC - Is the sequential block number reduced modulo 256
~REC - The ones-compliment of REC
checksum - an 8-bit sum of the preceding 128 data
bytes, formed by adding each byte to an
accumulator, then dropping all but the low order 8
bits of the result.
The intent of the additional characters is to facilitate
error checking and recovery, making the XModem protocol an
"error-free" means of data transfers under otherwise hostile
conditions.
The block number and its compliment are included to insure
that no blocks are accidentally lost during transmission,
and to prevent the accidental duplication of a data block
which might be caused by spurious line noise. The checksum
seeks to insure the validity of the actual data which might
become garbled by line noise. The fixed length block format
tends to simplify the logic required to implement the
protocol in the first place.
THE INTER-COMPUTER DIALOG
Xmodem is essentially uni-directional in nature. That is,
the actual flow of meaningful information occurs in one
direction at a time, from the sending computer to the
receiving computer. This is not meant to imply, however,
that only one computer sends and the computer receives. To
the contrary, there is a constant "dialog" going on between
the two computers during the course of the transmission. It
is this dialog that permits XModem to be true, "error-free"
transfer method.
CopyRight (c) 1987, 1988 Information Technology, Ltd.
LXM(tm) - LITECOMM (tm) XMODEM ENGINE for Microsoft
Datalight and Turbo C
Xmodem is a receiver-driven protocol. The receiving computer
initiates and almost exclusively controls the transmissions,
through a series of pre-planned responses. A typical, though
brief dialog might look like this:
RECEIVER SENDER MEANING
<NAK> --------------> READY TO RECEIVE
<------------- <BLOCK1> FIRST BLOCK SENT
<ACK> --------------> BLOCK RECEIVED OK
<------------- <BLOCK2> SECOND BLOCK
<NAK> --------------> ERROR, RESEND
<------------- <BLOCK2> SECOND BLOCK
<ACK> --------------> BLOCK RECEIVED OK
<------------- <EOT> END OF FILE
<ACK> --------------> E-O-F UNDERSTOOD
As you can see, it is through the responses to the sending
computer that the receiver controls the link.
Xmodem also makes provision for unusual circumstances by
providing both time-out and cancellation mechanisms. The
rules for time-outs, time periods which may elapse before a
disruption in transmission occurs are as follows:
1. Waiting for SOH - 10 seconds, Resend last
acknowledgement on time-out.
2. Waiting for other block characters - 1 second,
replace expected character with some pre-defined
value upon time-out.
3. Waiting for a reply to a block - 10 seconds,
Resend last block upon time-out.
CopyRight (c) 1987, 1988 Information Technology, Ltd.
LXM(tm) - LITECOMM (tm) XMODEM ENGINE for Microsoft
Datalight and Turbo C
The original protocol description also makes it possible for
either the sender or receiver to cancel the transmission.
This is of particular value when too many transmission
errors occur, or, in rare cases, when the physical
connection is broken. The threshold beyond which either side
may request cancellation, although specified as 10 attempts
in the original description of the protocol, has become
somewhat arbitrary over time. The cancellation code, <CAN>
or 0x10, may be sent by either the sender or receiver in
place of the <SOH> or normal acknowledgment character
respectively.
ENHANCEMENTS TO XMODEM
Over the years, several significant enhancements have been
made to the protocol as originally defined by Ward
Christiansen. The intent of these enhancements have
generally been to improve upon the error-handling capability
of the protocol, and to make the protocol more amenable to
some less time-efficient communications environments,
particularly those presented by for-pay services such as
CompuServe.
To make the protocol more error-free, the checksum employed
in the original design has been replaced by a 16 bit
calculation, called a Cyclical Redundancy Check or CRC.
Based upon a polynomial equation, the CRC method can be
mathematically demonstrated to be sensitive to all but about
.03 per cent of errors. This error detection rate, about
99.97 percent accurate, is far superior to the approximately
90 to 92 percent accuracy of the checksum approach. The
overhead of an additional 8 bits per message seems to make
this enhancement well worth while.
The second enhancement seeks to improve communication over
packet-switched networks, like those employed by CompuServe
and other national services. Basically this enhancement
introduces a relaxed time-out between characters in a block,
allowing additional time before the protocol recognizes a
time-out condition.
CopyRight (c) 1987, 1988 Information Technology, Ltd.
LXM(tm) - LITECOMM (tm) XMODEM ENGINE for Microsoft
Datalight and Turbo C
A third enhancement, variant of the original XModem protocol
seeks to improve overall efficiency by expanding the block
size from 128 characters to 1024 characters. This variant,
commonly call ymodem, reduces the number of times that an
acknowledgment sequence must be sent, thereby increasing the
efficiency of actual data transfer.
The LXM XModem engine supports all of the enhancements
mentioned above.
THE LXM ENGINE
OVERVIEW
One of the reasons for the popularity of the XModem protocol
over time is the simplicity of the implementation. Given a
reasonable communications package upon which to build,
developing a basic implementation of XModem is relatively
simple, although under certain operating systems, such as
the Unix family, the attempt of t